Comment deployer un NOC Agentic sur Proxmox VE

La gestion des infrastructures modernes exige une réactivité toujours plus forte de la part des administrateurs. Pour répondre à ce défi, le concept de NOC Agentic (Network Operations Center basé sur des agents IA) s'impose comme une révolution. Ce projet consiste à déployer un assistant virtuel intelligent et autonome, capable de surveiller un réseau d'entreprise, d'intercepter les anomalies en temps réel, de corréler les pannes et de rédiger instantanément des rapports de résolution complets.

Dans ce tutoriel complet, conçu pour être suivi pas à pas même si vous débutez totalement, nous allons bâtir cet écosystème sur l'hyperviseur Proxmox VE. Nous détaillerons l'installation d'Ubuntu Server, l'injection des modèles d'IA légers Llama3 et CodeLlama via Ollama, le déploiement de l'interface visuelle Open WebUI et l'intégration du collecteur de métriques Telegraf. Ce guide recense tous les cas de pannes réels et vous donne les solutions clés en main pour réussir sans aucune prise de tête.

Étape 1 : Configuration et installation d'Ubuntu Server sur Proxmox VE

Le cœur de notre agent NOC repose sur une machine virtuelle de la distribution Ubuntu Server LTS. Pour l'initialiser dans l'interface GUI de Proxmox, voici les spécifications matérielles et les cases à cocher indispensables à valider :

• CPU : Allocation de 4 à 8 vCPUs (idéal sur des processeurs multi-cœurs comme les processeurs Intel Xeon d'une workstation Proxmox).
• Memory (RAM) : Allouer un minimum strict de 8 Go à 16 Go de RAM pour assurer le chargement des modèles de langage en mémoire vive.
• Network : Sélectionner le pont virtuel standard (vmbr0).
• Options système : Cocher impérativement la case QEMU Guest Agent dans l'onglet "Options" après la création pour optimiser la communication entre l'OS invité et Proxmox.

Problème rencontré : Blocage complet sur "Installing Kernel"

Lors de la phase d'installation d'Ubuntu, le processus se fige brutalement à l'étape du déploiement du noyau à cause d'une connexion internet instable ou trop lente, empêchant la VM de récupérer les paquets distants requis.

Résolution de ce problème : Pour contourner ce blocage, il convient d'isoler temporairement la VM du réseau afin de forcer une installation locale :

1. Accédez à l'onglet Hardware de la VM sur l'interface Proxmox, sélectionnez la carte réseau (Net0) et cliquez sur "Edit" pour décocher l'option "Disconnect" (ou supprimez temporairement la liaison réseau).
2. Relancez l'installation d'Ubuntu, qui s'effectuera alors en mode local "hors-ligne" de manière instantanée.
3. Une fois l'installation logicielle finalisée et la VM démarrée, réactivez la carte réseau dans l'interface Proxmox.

Pour restaurer la connectivité internet sur la VM Ubuntu, ouvrez le fichier de configuration réseau Netplan :
sudo nano /etc/netplan/00-installer-config.yaml
Ajoutez-y une configuration DHCP standard (adaptez le nom de l'interface si nécessaire) :

network:
  ethernets:
    ens18:
      dhcp4: true
  version: 2

Appliquez ensuite les modifications pour relancer le service réseau :
sudo netplan apply

Contrôle de validation (Check) : Exécutez la commande ping google.com depuis le terminal de votre VM Ubuntu. Si les paquets répondent avec succès, votre système d'exploitation est validé et fonctionnel.

Étape 2 : Installation d'Ollama et déploiement des modèles IA Llama3 et CodeLlama

Pour faire fonctionner notre agent intelligent localement, nous déployons le moteur open-source Ollama. L'installation se fait en une seule ligne de commande dans le terminal Ubuntu :

curl -fsSL https://ollama.com/install.sh | sh

Une fois le moteur actif, nous téléchargeons et exécutons des modèles d'IA légers parfaitement calibrés pour les performances CPU d'un serveur ou d'une workstation :

• Llama3 (8B) : Ce modèle de 8 milliards de paramètres est idéal pour l'analyse globale, la classification d'incidents et la rédaction de synthèses textuelles claires pour le NOC. On l'exécute avec la commande : ollama run llama3.
• CodeLlama : Spécialisé dans la génération et l'analyse de code, ce modèle est parfait pour analyser les scripts d'automatisation, comprendre les configurations de routeurs ou générer des scripts de remédiation réseau. On l'installe via : ollama run codellama.

Le choix de ces versions "légères" permet une exécution fluide et une vitesse de génération stable en s'appuyant uniquement sur la mémoire RAM de la VM, sans nécessiter de carte graphique dédiée.

Contrôle de validation (Check) : Tapez la commande ollama list. Le terminal doit renvoyer un tableau propre affichant les lignes llama3:latest et codellama:latest avec leur taille respective.

Étape 3 : Déploiement d'Open WebUI via Docker et contournement des pannes réseau

L'outil Open WebUI sert d'interface graphique (GUI) pour chatter de façon conviviale avec nos modèles Ollama. Nous allons l'installer via un conteneur Docker. Si vous n'avez pas encore Docker sur votre machine, la commande de lancement s'occupe de le télécharger et de l'initialiser en arrière-plan d'un seul coup.

sudo apt update && sudo apt install -y docker.io

Problème rencontré n°1 : Échec et gel du téléchargement (Connection Reset)

En cas de connexion internet trop lente ou instable, la commande Docker de base échoue silencieusement. En inspectant les logs (sudo docker logs open-webui), on constate des erreurs de type Connection Reset : le conteneur n'arrive pas à télécharger ses modules internes indispensables au démarrage.

Problème rencontré n°2 : Statut Docker affiché en "Unhealthy"

Même si le conteneur démarre, un sudo docker ps montre un statut d'erreur critique : unhealthy. Le conteneur refuse de fonctionner car il ne parvient pas à joindre le moteur Ollama local.

Résolution de ce problème pour corriger et bypasser ces deux blocages :

Il est nécessaire de réinitialiser l'environnement de conteneurisation, de forcer le redémarrage des démons hôtes, puis d'exécuter une commande de déploiement modifiée qui s'appuie sur la configuration réseau locale de l'hôte :

1. Arrêter et purger le conteneur en échec :
   sudo docker stop open-webui && sudo docker rm open-webui
2. Redémarrer les processus systèmes pour réinitialiser les sockets :
   sudo systemctl restart docker
sudo systemctl restart ollama
3. Exécuter la commande de déploiement durcie (Bypass Internet lent & Unhealthy) :
   

   sudo docker run -d -p 3000:8080 -e OLLAMA_BASE_URL=http://127.0.0.1:11434 --network=host -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

   Note : L'ajout du paramètre --network=host et de la variable d'environnement -e OLLAMA_BASE_URL élimine le besoin de téléchargements réseaux superflus pour la découverte de services et lie directement l'IA à l'interface.

Contrôle de validation (Check) : Exécutez sudo docker ps. Le conteneur open-webui doit afficher le statut Up (healthy).
Comment se connecter : Ouvrez votre navigateur internet et rendez-vous sur l'URL : http://[IP_DE_LA_VM_UBUNTU]:3000 pour accéder à l'interface visuelle.

Étape 4 : Déploiement et initialisation de Telegraf au format Docker

Une IA a besoin de données fraîches à analyser. Pour que notre Agent NOC devienne proactif, il lui faut des "oreilles" sur le réseau d'entreprise. C'est le rôle exact de Telegraf. Cet agent de collecte ultra-léger va écouter en continu les messages d'alertes (Syslog) émis par les équipements réseau sur le port standard UDP 514.

Le format Docker garantit une isolation complète et une stabilité maximale sans altérer le système d'exploitation de la VM. Après avoir configuré votre fichier de base telegraf.conf, poussez cette commande unique dans le terminal pour installer et démarrer l'agent :

sudo docker run -d --name telegraf -p 514:514/udp -v ~/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro --restart always telegraf:latest

Contrôle de validation (Check) : Exécutez la commande sudo docker logs telegraf. Le terminal doit retourner la confirmation suivante : [inputs.syslog] Listening on udp://0.0.0.0:514, validant le bon fonctionnement de l'écoute des flux Syslog.

Résumé récapitulatif du fonctionnement de l'écosystème

Félicitations, votre architecture de supervision intelligente de niveau professionnel est opérationnelle ! Voici comment fonctionne la synergie de cet écosystème au quotidien :

1. Un incident survient sur l'infrastructure réseau (par exemple, la déconnexion d'un lien d'interconnexion).
2. L'équipement génère une alerte brute et l'envoie instantanément à la VM de supervision.
3. Le conteneur Telegraf intercepte ce message Syslog sur le port UDP 514.
4. Ce log est transmis au moteur Ollama qui sollicite le modèle de langage léger Llama3 ou CodeLlama.
5. L'IA traduit le log technique complexe en un langage clair, évalue l'impact sur le réseau et génère un rapport de résolution complet, immédiatement consultable par l'administrateur réseau au sein de l'interface graphique Open WebUI.